-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NETOBSERV-346 revamp upstream doc / readme #125
Conversation
Skipping CI for Draft Pull Request. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
WIP:
|
README.md
Outdated
|
||
## Understanding the deployed components | ||
|
||
TODO |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @netobserv/maintainers
does anybody have a full diagram depicting the architecture, including the epbf & kafka options? It would be nice to include here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
jira created to do it later: https://issues.redhat.com/browse/NETOBSERV-412
README.md
Outdated
#### To run the eBPF agent | ||
|
||
What matters is the version of the Linux kernel. | ||
TODO: precisions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mariomac do you know which minimal version is allowed here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We stated Kernel 4.18 or higher because it is supported by RHEL 8. Lower versions could still work, however.
README.md
Outdated
|
||
#### To use IPFIX exports | ||
|
||
OpenShift 4.10 or above, or upstream OVN-Kubernetes [TODO: upstream version?] are recommended, as the operator will configure OVS for you. Else, you need to configure it manually. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mariomac I didn't find how upstream ovn-k is versionned, do you know? their github doesn't tell much about it (or I missed it)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I'm sorry I don't know.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, my comment is just a suggestion
|
||
[![Docker Repository on Quay](https://quay.io/repository/netobserv/network-observability-operator/status "Docker Repository on Quay")](https://quay.io/repository/netobserv/network-observability-operator) | ||
A Kubernetes / OpenShift operator for network observability. It deploys a flow monitoring pipeline based on an [eBPF agent](https://github.com/netobserv/netobserv-ebpf-agent/) or [IPFIX](https://en.wikipedia.org/wiki/IP_Flow_Information_Export) exports. It provides dashboards, metrics, and keeps flows accessible in a queryable log store: [Grafana Loki](https://grafana.com/oss/loki/). When used in OpenShift, new dashboards are available in the Console. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about adding a screenshot here to show what the NOO can do?
May be we can reuse the topology screenshot?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was also thinking about showing a top banner, like on operatorhub: https://operatorhub.io/operator/netobserv-operator/
but actually, I don't know, we don't want too many screenshots either, as it takes a lot of space and forces to scroll more...
There's now 6 screenshots in this version (compared to 3 before, and they were buried at the bottom of the page), I would have said it's enough (?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I understand your point of not having too many screenshots.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if you want to put a lot of screens, what about making a dedicated page for that ? and we keep only top 3 items in the main page.
New changes are detected. LGTM label has been removed. |
kubectl apply -f ./config/samples/flows_v1alpha1_flowcollector.yaml || true | ||
else | ||
kubectl apply -f ./config/samples/flows_v1alpha1_flowcollector_versioned.yaml || true | ||
endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove "|| true". If this fails, do you really want the next potential target to continue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is what @eranra wrote, on purpose I think .. I'm not against discussing that, but it doesn't really relate to that PR
To bring some context: I did did small change in the makefile because, while writing the doc, I figured out that deploying a "versionned" sample CR wouldn't work as expected, especially as the underlying component images are not tied anymore with the operator version. So now, I recommend switching to the version tag in git before deploying / applying CR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, that change is fine. We can ignore my comment.
README.md
Outdated
|
||
- Agent (`spec.agent`) can be `ipfix` or `ebpf`. As mentioned above, the IPFIX option is fully functional when using OVN-Kubernetes CNI (other CNIs are not supported, but you may still be able to configure them manually if they allow IPFIX exports) whereas eBPF is expected to work regardless the running CNI. | ||
|
||
- Sampling (`spec.ipfix.sampling` and `spec.ebpf.sampling`): 24/7 unsampled flow collection may consume a non-negligible amount of resources. While we are doing our best to make it a viable option in production, it is still often necessary to mitigate by setting a sampling ratio. A value of `100` means: one flow every 100 is sampled. `1` means no sampling. The lower it is, the more accurate are flows and derived metrics. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Specify the sampling defaults for ipfix and ebpf.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
@mariomac , looking for default sampling in eBPF, I see it is disabled. Is it on purpose? Shouldn't we set a bigger value, maybe 100, at least until the epbf perf enhancement epic is completed?
Second question: a default of 0 is explicitely set in the sample CR (which is used by OLM) but not via kubebuilder / CRD. I guess that means it defaults to golang's 0-value, hence 0 too ? But we should set an explicit value if we want to enable sampling by default
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it was on purpose. Even if it can be vastly improved, we considered the performance as "good enough". I'd keep it as disabled, considering that eBPF right now is not the default agent.
Second question: yes, we assumed it would default to 0. We can set it explicitly to 0 or 1 if you prefer to make it clearer. Or to another value if you consider that we should enable sampling by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough, let's keep it that way :)
Thank you @stleerh 🙏 |
/retest |
README.md
Outdated
_Pod traffic_ | ||
This project is licensed under [Apache 2.0](./LICENSE) and accepts contributions via GitHub pull requests. Other related `netobserv` projects follow the same rules: | ||
- [Flowlogs-pipeline](https://github.com/netobserv/flowlogs-pipeline) | ||
- The [eBPF agent](https://github.com/netobserv/netobserv-ebpf-agent) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove 'The' here too.
/approved |
@stleerh I'm going to merge it. We can continue discussion & refine before we release final v0.1.3 |
add filter transform
No description provided.